1. Field of the Invention
The present application relates to improving TCP throughput in a wireless communications network, and more particularly to reducing TCP acknowledgment delays by separation of TCP acknowledgment transmissions in wireless networks.
2. Description of Related Art
Supporting TCP/IP based applications is mandatory in today's networking world. Users' demands for mobile services are increasing with greater diversity and complexity for the mobile communications market. Diverse and complex services are presenting unique challenges in supporting TCP/IP based applications in wireless environment.
IP applications over mobile systems are supported by existing standards that use IP to send data. However, to support enhanced IP applications such as FTP, HTTP and multimedia data services, mobile system applications rely on TCP (Transmission Control Protocol) to provide connection-oriented reliable byte-stream services.
The Transmission Control Protocol (TCP), documented in IETF RFC 793, makes up for IP's deficiencies by providing reliable, stream-oriented connections that hide most of IP's shortcomings. Transmission of a data packet is not regarded as complete until a corresponding acknowledgement packet (“ACK”) is received. TCP adds a great deal of functionality to the IP service it is layered over.
FIG. 5(e) schematically shows how a segmented application message is encapsulated into a TCP segment, which is itself encapsulated in an IP packet.
FIG. 5(a) gives a large-scale view of a TCP/IP protocol architecture. IP applications over mobile systems are supported by existing standards that use IP 510 to send data. However, enhanced IP applications such as FTP 540, HTTP 530 and multimedia data services, which are desirable for use in mobile systems, rely on TCP 520 (Transmission Control Protocol) to provide connection-oriented reliable byte-stream services.
TCP algorithms operate in both directions, in an almost completely independent manner. A TCP session can be thought of as two independent byte streams, traveling in opposite directions. No TCP mechanism exists to associate data in the forward and reverse byte streams. Only during connection start and close sequences can TCP exhibit really asymmetric behavior (i.e. data transfer in the forward direction but not in the reverse, or vice versa).
Thus TCP is inherently duplex. (Duplex communications are the type of communications that transmissions can simultaneously happen at both directions.) However, if TCP data flow and TCP ACK flow are examined separately, TCP for some applications can be half duplex, or even simplex. Applications like FTP download are simplex: data is sent in only one direction (though control messages like request and ACK are sent in another direction at the same time). Applications like Database query are half duplex: data is sent in one direction in one time, then sent in another direction in other times. (Again, TCP control messages including TCP ACK can be sent in both directions simultaneously).
For duplex communications (where data is sent in both directions simultaneously), TCP employs a technique called piggybacking. Basically, TCP ACK info is carried on a TCP data segment. (ACK field in TCP header indicates whether the data segment contains ACK info or pure data). In that case the data and acknowledgement flows cannot be strictly separated.
Sequence Numbers
TCP uses a 32-bit sequence number that counts bytes in the data stream. Each segment (TPDU) contains the starting sequence number of the data in that segment, and the sequence number (called the acknowledgment number) of the last byte received from the remote peer. With this information, a sliding window protocol is implemented. Forward and reverse sequence numbers are completely independent, and each TCP peer must track both its own sequence numbering and the numbering being used by the remote peer.
TCP uses a number of control flags to manage the connection. Some of these flags pertain to a single packet, such as the URG flag indicating valid data in the Urgent Pointer field, but two flags (SYN and FIN) require reliable delivery as they mark the beginning and end of the data stream. In order to insure reliable delivery of these two flags, they are assigned spots in the sequence number space. Each flag occupies a single byte.
Window Size and Buffering
Each endpoint of a TCP connection will have a buffer for storing data that is transmitted over the network before the application is ready to read the data. This lets network transfers take place while applications are busy with other processing, improving overall performance.
FIG. 6 shows the relationship of TCP window size and delay. To avoid overflowing the buffer, TCP sets a Window Size field in each packet it transmits. In this example, it is set to w (reference number 610). This field contains the amount of data that may be transmitted into the buffer. If this number falls to zero, the remote TCP can send no more data. It must wait until it receives a packet announcing a non-zero window size.
Round-Trip Time Estimation
When a host transmits a TCP packet to its peer, it must wait a period of time for an acknowledgment 620. If the reply does not come within the expected period, the packet is assumed to have been lost and the data is retransmitted. The best value for the maximum wait depends on many factors. Over an Ethernet connection, no more than a few microseconds should be needed for a reply. If the traffic must flow over the wide-area Internet, a second or two might be reasonable during peak utilization times.
All modern TCP implementations seek to answer this question by monitoring the normal exchange of data packets and developing an estimate of how long is “too long”. This process is called estimation of Round-Trip Time (RTT) 630. RTT estimates are one of the most important performance parameters in a TCP exchange. This is especially clear if we consider that, on a sufficiently large transfer, all TCP implementations eventually drop packets and retransmit them, no matter how good the quality of the link. If the RTT estimate is too low, packets are retransmitted unnecessarily; if too high, the connection can sit idle while the host waits to timeout.
Thus TCP throughput performance is greatly affected by the delay characteristics of the network which is carrying the IP packets. In a wireless environment the delay characteristics of the network can be more unpredictable, due e.g. to multipath characteristics, delays due to ARQ (automatic repeat request), and other factors discussed below.
The TCP sender bases its retransmission timeout (RTO) on measurements of the round trip delay experienced by previous packets. This allows TCP to adapt automatically to the very wide range of delays found on the Internet. If the path delay variance is high, TCP sets an RTO that is much larger than the mean of the measured delays. If the packet loss rate is low, the large RTO is of little consequence, as timeouts occur only rarely. Conversely, if the path delay variance is low, then TCP recovers quickly from lost packets; again, the algorithm works well. However, when delay variance and the packet loss rate are both high, these algorithms perform poorly, especially when the mean delay is also high.
Because TCP uses returning acknowledgments as a “clock” to time the transmission of additional data, excessively high delays (even if the delay variance is low) also affect TCP's ability to fully utilize a high-speed transmission pipe. It also slows the recovery of lost packets, even when delay variance is small.
Mobile systems should therefore minimize all three parameters (delay, delay variance, and packet loss) as much as possible. Often these parameters are inherently in conflict. For example, on a mobile radio channel, retransmission (ARQ) and/or forward error correction (PEC) can be used to trade off delay, delay variance, and packet loss in an effort to improve TCP performance. While ARQ increases delay variance, FEC does not. However, FEC (especially when combined with interleaving) often increases mean delay, even on good channels where ARQ retransmissions are not needed and ARQ would not increase either the delay or the delay variance.
The tradeoffs among these error control mechanisms and their interactions with TCP can be quite complex, and are the subject of much ongoing research. The common solution today is to adjust buffer sizes based on RTT estimate. For instance, when RTT increases, throughput is guaranteed by increasing the buffer size because Buffer_size=RTT* Bandwidth.
However, increasing buffer size will increase the cost of equipment. Further, it might worsen the delay since allowing more outstanding unacknowledged TCP segments will further congest the network or its communication peer.
Multi-Flow Packet Application
The Multi-Flow Packet Application provides multiple octet streams that can be used to carry octets between the access terminal and the access network.
CDMA2000 1x EV-DO
CDMA2000 1x EV-DO cell phone system is a standard that has evolved from the CDMA2000 mobile phone system and is now firmly established in many areas of the world. The letters EV-DO stand for Evolution Data Only or Data Optimized. It is a data only mobile telecommunications standard that can be run on CDMA2000 networks.
The forward channel forms a dedicated variable-rate, packet data channel with signaling and control time multiplexed into it. The channel is itself time-divided and allocated to each user on a demand and opportunity driven basis. A data only format was adopted to enable the standard to be optimized for data applications. If voice is required then a dual mode phone using separate 1X channel for the voice call is needed. In feet the “phones” used for data only applications are referred to as Access Terminals or ATs.
The forward link possesses many features that are specific to EV-DO, having been optimized for data transmission, particularly in the downlink direction. Average continuous rates of 600 kbps per sector are possible. This is a sixfold increase over CDMA2000 1X and is provided largely by the ability of 1xEV-DO to negotiate increased data rates for individual ATs because only one user is served at a time.
The forward link is always transmitted at full power and uses a data rate control scheme rather than the power control scheme used with 1X, and the data is time division multiplexed so that only one AT is served at a time.
In order to be able to receive data, each EV-DO AT measures signal-to-noise ratio (S/N) on the forward link pilot every slot, i.e. 1.667 ms. Based on the information this provides the AT sends a data rate request to the base station. The AN receives requests from a variety of ATs, and decisions have to be made regarding which ATs are to be served next. The AN endeavors to achieve the best data transfer, and this is done by serving those ATs offering a good signal-to-noise ratio. This is achieved at the expense of users at some distance from the AN's antenna.
Protocol Layering
Many telecommunications standards are defined in a layered structure. FIG. 4 shows an example of this (the HRPD air interface for the CDMA2000). The layered structure of the protocol will be helpful in understanding the operation of the implementations described below. Each layer consists of one or more protocols that perform the layer's functionality.                The Application Layer 410: provides multiple applications, including the Default Signaling Application for transporting air interface protocol messages. It also provides the Default Packet Application for transporting user data.        Stream Layer 420: The Stream Layer provides multiplexing of distinct application streams.        Session Layer 430: The Session Layer provides address management, protocol negotiation, protocol configuration and state maintenance services.        Connection Layer 440: The Connection Layer provides air link connection establishment and maintenance services.        Security Layer 450: The Security Layer provides authentication and encryption services.        MAC Layer 460: The Medium Access Control (MAC) Layer defines the procedures used to receive and to transmit over the Physical Layer.        Physical Layer 470: The Physical Layer provides the channel structure, frequency, power output, modulation, and encoding specifications for the Forward and Reverse Channels.Each layer may itself contain one or more protocols. Protocols use signaling messages or headers to convey information to their peer protocols at the other side of the air-link.        